feat(bridge): session start-queue for extension-created sessions (#1328) - #1330

…de.ai's repo picker (#1328) (#1693)

* Web runs: the Chrome extension creates the cloud session through claude.ai's repo picker (#1328)

A session created through the page's repository picker is repo-bound and can push and
open its pull request; `claude --cloud` has, on some accounts, produced a bundle upload that
never could (#1320). So a web run now asks its daemon for an extension-created session first.

Daemon: the session start-queue (`bridge-starts.ts`, re-landed from #1330) behind two faces on
the one token — the extension's `GET /_bridge/start` (claim-on-read) + `POST /_bridge/started`,
and the run's `POST /_web-start` + `GET /_web-start/<id>` (`web-start-endpoints.ts`), which
answers 409 at once when no extension has called within three minutes. The daemon hands every
spawned run its own URL in `TF_DAEMON_URL`.

Driver: `CloudDriver` takes `extension: { daemonUrl, token }` (wired by the CLI from the env
and the registry token); after the anchor push and trust check it posts the request — repo from
the GitHub remote, the pushed ref, the whole hand-off prompt — and polls until created, then
reports exactly as the CLI path does. 409/404, no GitHub remote or an unpushed ref fall back
to the CLI's cloud mode with a notice; an extension that tried and failed fails the turn with
its note.

Extension 0.11.0 (daemon lockstep): the worker claims requests on the answer beat, one at a
time, opens claude.ai/code pinned and inactive, and the content script drives the repo chip's
searchable list, verifies the branch chip reads the pushed ref before sending, types the prompt,
sends, and reads the session id off the address. A created session's tab is a watched tab; a
failed attempt's tab is closed and the note says what the page lacked. Harness cases cover
the drive, the wrong-branch refusal and the missing-picker report.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Extension: wait for the repo chip or picker to render, and treat a remembered repo's chip as the picker (#1328 dogfood 1)

First live attempt: the page had remembered the last repo picked, so its chips (the-framework / main, as comboboxes)
were already there — but they render after the composer, and createSession read the page before they did, then looked
for a "Select repo" trigger that no longer exists once a repo is remembered.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Extension: drive the new-session page as it actually is — combobox chips in order, visible options only, React-safe search (#1328 dogfood 2)

Run 2 clicked the repo chip itself as if it were a list entry (its text is the bare repo name) and then found no
chip "afterwards". Read from the live page: the chips are combobox buttons in the order repo, branch, add; a picker
is a dialog with a role=combobox search input and a listbox of options; a closed picker's options stay in the DOM,
so only visible options are entries, and the trigger is never one. The branch list does offer a ref pushed seconds
earlier (checked live), so verifying the chip before sending is enough.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Extension: wait for the picker's list to load before filtering it, fall back to the whole list, and say what the list showed on failure (#1328 dogfood 3)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Harness: a list that already holds the entry is not filtered first

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Extension: read chip and entry labels through the page's icon-font glyphs (#1328 dogfood 4)

In the content script's world the labels carry private-use glyphs — the chips read "\ue048the-framework" and
"\ue078main", the chosen entry "framework/the-framework\ue03b" — so no exact match ever fired. The mirror already
strips those; the control labels now do too.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>